adapter: remove ENABLE_CLUSTER_CONTROLLER and the legacy REFRESH scheduler - #38101

…nc#38102)

Part 2 of 3 of the [design][design] for removing the legacy cluster
paths.
Stacked on MaterializeInc#38101. Part 3 stacks on this one.

[design]:
https://github.com/MaterializeInc/materialize/blob/aljoscha/cluster-legacy-05-design/doc/developer/design/20260724_cluster_controller_legacy_removal.md

## Why

System/builtin clusters were excluded from the controller's ownership
(`ManagedClusterIds` and the sequencer's two ownership tests all
required
`is_user()`), so the sequencer had to keep a second, complete
replica-materialization implementation alive just for them.

The exception was originally load-bearing: the boot-time builtin replica
migration and the controller would have been two conflicting writers of
one
replica set. MaterializeInc#37929 removed that conflict.
`reconcile_builtin_cluster_replicas`
now converges a builtin cluster's replica set on the cluster's own
managed
config, the same config the controller derives its targets from, so the
two
converge on the same set by construction.

## What lands

Drop the three `is_user()` conjuncts. Runtime ALTERs of system clusters
now
flow through the controller like any other managed cluster: a
config-shape
change reshapes into a durable reconfiguration record, a factor change
updates
the config and the controller converges the replica set within a tick.

Ownership and the boot migration compose in both directions. The
controller
matches replicas by shape and count, never by name, so the
migration-created
`r1..rN` satisfy its baseline and a steady system cluster reconciles to
no
decisions. The migration converges by canonical name, so a boot after a
reshape
(or with a reconfiguration in flight) renames or re-creates replicas the
controller materialized under generator names. That is harmless churn:
every
replica is a cold process at boot anyway, so the cost is replica-id and
audit-log noise, and an in-flight record is durable, so the controller
picks the
reconfiguration back up on its first tick.

Boot ordering and 0dt read-only behavior are unchanged.
`reconcile_builtin_cluster_replicas` still runs at catalog open, which
is what
gets system clusters up and hydrated before the serve loop starts and
before a
0dt cutover. The controller cannot cover either window:
`Coordinator::bootstrap`
runs before the controller task is spawned, and the controller is
inactive while
read-only.

Also rewrites the comment in `validate_reconfiguration_resource_limits`.
The
early return for non-user clusters stays, since system clusters are
exempt from
`max_replicas_per_cluster` and credit accounting everywhere else, but
the reason
it gave ("a system cluster never reshapes into a record") is now false.

## Behavior changes

- `ALTER CLUSTER mz_system SET (SIZE ...)` goes from a synchronous
whole-set
recreation to a background graceful reconfiguration (default deadline
24h,
`ROLLBACK` on timeout). Strictly more capable: the graceful path did not
exist
  for system clusters before, and part 3 adds `WITH (WAIT FOR '0s')` for
  operators who cannot afford the overlap set.
- `ALTER CLUSTER mz_support SET (REPLICATION FACTOR 1)` updates the
config and
returns; the controller materializes the replica within a tick. Same as
user
  clusters today.

## Tests

- `test/sqllogictest/system-cluster.slt`: the block asserting a replica
count
right after a factor flip is reworked. slt does not retry, so it now
asserts
the declared factor (synchronous) and phrases the system-id property as
"no
replica that isn't system-id'd", which holds regardless of convergence.
- `test/testdrive/system-cluster.td` (which does retry) picks up the
convergence coverage: factor up materializes exactly one system-id
replica,
a `SIZE` reshape cuts the realized config over and leaves exactly one
replica
at the new size, and factor back to 0 retires it with no activity left
behind.
- `src/environmentd/tests/bootstrap_builtin_clusters.rs`: the three
assertions
  that immediately follow a runtime `ALTER CLUSTER` now poll
(`await_declared_and_actual`). The bootstrap and post-restart assertions
stay
  exact, since the catalog-open migration converges synchronously.
- `test/cluster/resources/resource-limits.td` already uses retrying
queries for
  its `mz_analytics` factor flips, so it survives unchanged and pins the
  system-cluster limit exemption end to end.
- Docs: the self-managed troubleshooting guide's `mz_catalog_server`
resize
walkthrough gets a note that the resize is a graceful reconfiguration
and
  `SHOW CLUSTERS` settles rather than flips.